test: update test_request_deduplication_edge_cases#884
Conversation
vdusek
left a comment
vdusek
left a comment
There was a problem hiding this comment.
Thanks, but I would rather see the root cause investigation and actually trace where the empty processedRequests comes from, rather than retry in test workaround 🙂.
It's a frustrating answer, but due to the nature of the Request Queue, this sometimes just... happens. It is an established fact that the API leaks implementation details. Maybe we should make sure we plug that leak at the SDK level at least, though. |
Yeah, in that case, we should try to address this in the |
vdusek
left a comment
vdusek
left a comment
There was a problem hiding this comment.
I just utilized the poll_until_condition, otherwise LGTM.
vdusek
force-pushed
the
update-test_request_deduplication_edge_cases
branch
from
96e5038 to
c90b05e
Compare
Replace the no-delay retry loop with the poll_until_condition helper so transient platform-side None results have time to clear between attempts.
vdusek
force-pushed
the
update-test_request_deduplication_edge_cases
branch
from
c90b05e to
f5835aa
Compare
4 participants
Closes: #786
Re-enables
test_request_deduplication_edge_casesin shared mode (previously skipped as flaky).The flakiness came from
add_requestoccasionally returningNonetransiently due to platform-side propagation in shared request-queue mode. Instead of a fixed retry loop with no delay between attempts, the test now uses thepoll_until_conditionhelper, which pollsadd_requestwith backoff until it returns a result (or times out). This gives transientNoneresults time to clear and is consistent with how other integration tests handle eventually-consistent API state.